Fix #15217 (gtk.cfg: g_idle_add and g_timeout_add take the data pointer) - #9008

AI review

This PR causes a new false negative: leaks of a GMainContext passed to g_main_context_invoke / g_main_context_invoke_full are no longer reported. CheckLeakAutoVarImpl::functionCall applies a <use> function to every plain pointer variable in the call, because <use> has no argument number. So g_main_context_invoke(ctx, cb, NULL) now marks the context in ctx as taken over. That context comes from g_main_context_new(), which is in the g_main_context_unref group. GLib does not take ownership of the context; it only refs it internally. The base config reports Memory leak: ctx for this code; the PR does not. g_idle_add* and g_timeout_add* don't have this problem, because their only pointer parameters are the callback, the data and the destroy notify.

The memleak false positives that the PR is about are gone, and test/cfg/gtk.c passes. The new <arg> configuration for g_main_context_invoke* works: it reports a NULL callback as nullPointer and an uninitialized callback or priority as uninitvar.

Testing

Build: make -j8 cppcheck testrunner in pr/ succeeded.

cfg test: I ran test/cfg/gtk.c with the runtests.sh options (--check-library --platform=unix64 --enable=style,information --inconclusive --force --check-level=exhaustive --inline-suppr ... --library=gtk).

• With the PR's gtk.cfg: clean, exit code 0.
• With the base gtk.cfg: 8 memleak errors in the new test functions. So the test does cover the change.

Regression found (I compared the PR's cfg with a copy of base's gtk.cfg, both run with the PR binary, since only the cfg changed):

static gboolean cb(gpointer data) { g_free(data); return FALSE; }
void ctx_leak(void)
{
    GMainContext *ctx = g_main_context_new();
    g_main_context_invoke(ctx, cb, NULL);
}
void ctx_ok(void)
{
    GMainContext *ctx = g_main_context_new();
    g_main_context_invoke(ctx, cb, NULL);
    g_main_context_unref(ctx);
}

$ cppcheck -q --library=/tmp/b/gtkbase.cfg t2.c
t2.c:16:1: error: Memory leak: ctx [memleak]
$ cppcheck -q --library=pr/cfg/gtk.cfg t2.c
(no output)

g_main_context_invoke_full(ctx, 0, cb, NULL, NULL) behaves the same way: base reports the leak, the PR does not.

Other checks:

• g_main_context_invoke(NULL, NULL, NULL) now gives nullPointer, and an uninitialized callback or priority gives uninitvar.
• A malloc'd or g_new'd pointer passed as the data is no longer reported, and no mismatch is reported either.
• A conditional if (x) g_idle_add(cb, p); is no longer reported. That matches how if (x) g_free(p); is already handled, so I don't count it as a problem of this PR.

Automated review of 51b97a0 by Claude. The pull request was built and tested locally.

AI review

The earlier problem is fixed: the PR no longer touches g_main_context_invoke*, so a leaked GMainContext is reported again. The memleak false positives that the PR is about are gone, and test/cfg/gtk.c passes.

New finding (minor false negative): removing <leak-ignore/> also removes the use-after-free check for these calls. With base, g_free(p); g_idle_add(cb, p); gives deallocuse. With the PR it gives nothing. In CheckLeakAutoVarImpl::functionCall, only leak-ignore functions go through checkTokenInsideExpression; a <use> function only changes the pointer's alloc status. Every <use> function behaves this way, so this is a trade-off of the approach rather than a bug in the cfg. It could still be pinned down with a test in test/cfg/gtk.c. I found no other problems.

Earlier comments

Testing

Build: make -j8 cppcheck in pr/ succeeded. Only the cfg changed, so I compared the PR's cfg/gtk.cfg with a copy of base's gtk.cfg, both run with the PR binary.

cfg test: I ran test/cfg/gtk.c with the runtests.sh options (--check-library --inline-suppr --error-exitcode=1 ... --library=gtk). It was clean, exit code 0.

Scratch test (scratch/t.c):

#include <glib.h>
#include <stdlib.h>
static gboolean cb(gpointer d){g_free(d);return FALSE;}
void a(void){ gchar *p=g_strdup("x"); g_idle_add(cb,p); g_free(p); }
void b(void){ gchar *p=g_strdup("x"); g_free(p); g_idle_add(cb,p); }
void c(void){ char *p=malloc(3); g_idle_add(cb,p); free(p); }
void d(void){ gchar *p=g_strdup("x"); gchar *q=g_strdup("y"); g_timeout_add(1,cb,p); }
void e(int x){ gchar *p=g_strdup("x"); if(x) return; g_idle_add(cb,p); }
void f(void){ g_idle_add(cb,g_strdup("x")); }
void g(void){ GMainContext *ctx=g_main_context_new(); g_main_context_invoke(ctx,cb,NULL);}
void h(void){ gchar *p=g_strdup("x"); g_idle_add_full(0,cb,p,g_free); g_free(p);}

$ cppcheck -q --library=gtkbase.cfg --template='{line}:{id}:{message}' t.c
5:deallocuse:Dereferencing 'p' after it is deallocated / released
7:memleak:Memory leak: p
7:memleak:Memory leak: q
8:memleak:Memory leak: p
10:memleak:Memory leak: ctx
9:leakNoVarFunctionCall:Allocation with g_strdup, g_idle_add doesn't release it.
$ cppcheck -q --library=pr/cfg/gtk.cfg --template='{line}:{id}:{message}' t.c
7:memleak:Memory leak: q
8:memleak:Memory leak: p
10:memleak:Memory leak: ctx

• Lines 7, 8 and 9: the PR removes the intended false positives. The real leaks (q, and the early-return path) are still reported.
• Line 10: the GMainContext leak from the earlier review is reported again.
• Line 5: the deallocuse warning (use after free) is lost, which is the new false negative.
• Lines 4 and 11: the double free through the callback is not reported, with base or with the PR.

Automated review of 46f1427 by Claude. The pull request was built and tested locally.

AI review

I found no new problems. The two issues raised earlier are dealt with:

• The false negative for a GMainContext leak through g_main_context_invoke* is fixed, because those functions were dropped from the PR.
• The lost deallocuse check for these six functions is still there. It is a limitation of <use> itself, and the PR now records it as a TODO suppression in test/cfg/gtk.c.

The memleak false positives the PR targets are gone. Real leaks of other variables are still reported.

Earlier comments

Testing

Build: make -j8 cppcheck in pr/ succeeded.

cfg test: I ran test/cfg/gtk.c with the PR binary and --library=gtk, using the runtests.sh style options including --debug-warnings and --inline-suppr. The only messages were unmatched suppressions for the extra --suppress options that I had passed myself. The test file gave no warnings.

Scratch comparison: I ran the PR binary on the same file twice, once with base's gtk.cfg and once with the PR's gtk.cfg:

static gboolean cb(gpointer d){return FALSE;}
void a(void){ GHashTable *h = g_hash_table_new(NULL,NULL); g_idle_add(cb,h); }
void b(void){ GObject *o = g_object_new(0,NULL); g_timeout_add(1,cb,o); }
void c(void){ GList *l = g_list_alloc(); g_idle_add(cb,l); }
void d(void){ GString *s = g_string_new("x"); g_idle_add(cb,s); }
void e(void){ gchar *p = g_strdup("x"); g_idle_add(cb,p); g_free(p); }
void f(void){ gchar *p = g_strdup("x"); g_idle_add(cb,p); p[0]=0; }
void g(void){ gchar *p = g_strdup("x"); guint id = g_idle_add(cb,p); (void)id; }
void h(void){ GHashTable *h = g_hash_table_new(NULL,NULL); g_idle_add(cb,h); g_hash_table_unref(h);}

• Base cfg: memleak in a, b, c, d, f and g, plus constVariablePointer for the data variables.
• PR cfg: none of these. Only the unrelated constParameterCallback remains.

Data from other allocator groups (hash table, GObject, GList, GString) is now treated as handed over. I saw no new mismatch or double-free false positives.

Automated review of c10a655 by Claude. The pull request was built and tested locally.